Skip to content

feat(model-manager): support LyCORIS LoKr LoRAs for Krea-2 - #9424

Open
Balrog994 wants to merge 1 commit into
invoke-ai:mainfrom
Balrog994:feat/krea2-lokr-lora-support
Open

feat(model-manager): support LyCORIS LoKr LoRAs for Krea-2#9424
Balrog994 wants to merge 1 commit into
invoke-ai:mainfrom
Balrog994:feat/krea2-lokr-lora-support

Conversation

@Balrog994

Copy link
Copy Markdown

Summary

Krea-2 LoRAs in LyCORIS LoKr format can't be installed at all at the moment. The probe turns them away with:

model does not match Krea-2 LoRA heuristics (no complete lora_A/B or lora_down/up pair)

I hit this with an adapter trained in ai-toolkit, which emits LoKr by default, so I'd guess a fair few of the Krea-2 LoRAs going around are in the same boat.

The Krea-2 probe only knows about lora_A/lora_B and lora_down/lora_up. LoKr carries Kronecker factors instead (lokr_w1/lokr_w2, or the factored _a/_b pairs plus an optional lokr_t2), so _has_complete_lora_pair() says no and the adapter is never identified. Setting the base by hand doesn't get you anywhere either, that path goes through the same helper.

There's a second one further down: _SUFFIX_TO_VALUE_KEY doesn't list the lokr_* suffixes, so even past the probe _group_by_layer() would drop the weights and leave every layer holding nothing but its alpha.

The rest was already there. LoKRLayer exists, any_lora_layer_from_state_dict() reaches for it the moment it sees lokr_w1, and the Qwen-Image converter handles LoKr fine. Only the Krea-2 side was never wired up, which fits it being marked WIP in #9304.

So this adds the two missing pieces: a _has_lokr_layer() helper that both config gates consult, and the lokr_* suffixes in the converter's suffix map. I left the signature-module check alone, so a LoKr that only touches generic transformer blocks still won't be claimed as Krea-2.

Related Issues / Discussions

Follows on from #9304.

QA Instructions

Take any ai-toolkit LoKr for Krea-2 (keys look like diffusion_model.txtfusion.<block>.attn.wq.lokr_w1) and install it through the Model Manager. Before, it's rejected with the error above. After, it installs as base=krea-2, format=lycoris and turns up in the LoRA picker.

I tested with a 32-module adapter on the text-fusion stage against a GGUF-quantised Krea-2 Turbo. It converts to 32 LoKRLayers, every target key resolves to a real nn.Linear in Krea2Transformer2DModel, the reconstructed weight (4×4 ⊗ 640×640 = 2560×2560) matches the layer it patches, and generation comes out visibly different with the LoRA switched on.

8 new tests, covering full and factored LoKr, the native→diffusers key renaming, and that a LoKr without the Krea-2 signature modules still gets turned away. tests/backend/patches/ and tests/backend/model_manager/ pass (1030 passed, 133 skipped, 1 xfailed), as do ruff check and format. I only ran them on 3.12/Windows locally, so the rest of the matrix is on CI.

Merge Plan

Nothing special, backend only.

Checklist

  • The PR has a short but descriptive title, suitable for a changelog
  • Tests added / updated (if applicable)
  • ❗Changes to a redux slice have a corresponding migration
  • Documentation added / updated (if applicable)
  • Updated What's New copy (if doing a release after this PR)

Krea-2 LoRAs in LyCORIS LoKr format were rejected at install time and could
not be used. LoKr is the default output format of ai-toolkit, so this affects
a fair number of community adapters.

Two gaps in the Krea-2 path:

- `LoRA_LyCORIS_Krea2_Config` required a complete lora_A/B or lora_down/up
  pair. LoKr carries Kronecker factors instead, so the probe rejected it even
  though the Krea-2 signature modules matched. The explicit-base override went
  through the same helper, so forcing the base did not help either.
- `_SUFFIX_TO_VALUE_KEY` did not map the lokr_* suffixes, so `_group_by_layer`
  would have dropped the weights and left each layer holding only its alpha.

The rest of the stack already handles LoKr: `LoKRLayer` exists and
`any_lora_layer_from_state_dict` routes to it on `lokr_w1` / `lokr_w1_a`. Only
the Krea-2 wiring was missing, matching its (WIP) status in invoke-ai#9304.

The Krea-2 signature-module requirement is unchanged, so a LoKr targeting only
generic transformer blocks is still not claimed by this base.
@github-actions github-actions Bot added python PRs that change python files backend PRs that change backend files python-tests PRs that change python tests labels Jul 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backend PRs that change backend files python PRs that change python files python-tests PRs that change python tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant